Hi, Considering my knowledge of DXL it is not possible to evaluate a DXL string in a current DXL context. I see may be and "half-solution" by evaluating ad DXL string that contain an address of a DxlObject that could contains references to the needed elements of the context. Does someone has an "at least almost elegant" solution for that ? Thanks in advance for your help. Joseph. jaracic - Tue Nov 03 09:43:19 EST 2015 |
Re: Evaluate a DXL script in the current context I think I could use more details before I can understand the question |
Re: Evaluate a DXL script in the current context Hello Joseph,
you can hand any variable to an eval_ DXL context using addr this way:
DxlObject dx = new()
string sCode = "
DxlObject dx = addr_ (" ((addr_ dx) int) ")
// ... work with dx ...
"
However you need to be very careful with what you hand out of the eval context. If you put something inside a skip list or dxl object or such from inside the eval context, chances are high, that it will be destroyed after eval context ends. I found it is save to append to a Buffer declared on the outside from the inside of the eval context. You can also pass a reference to the eval_ context, allowing you change the outside variable, but this needs to be handled with even more care: Buffer buf = null string sCode = " Buffer &buf = addr_ " ((addr_ (&buf)) int) " buf = create() // ouch! will change the outside buf " Ouch, because inside the above code the eval will be able change the outside buf variable, but the allocation will be freed after the eval context ends. One important note regarding the addr_: The eval string will end up like so: " Buffer buf = addr_ 1234567" where 1234567 is the content of the variable (or memory address if you use the reference). You need to be especially careful on DOORS 64 since memory addresses are 64 bit and this kind of code will fail for high memory addresses. Hope that helps, regards, Mathias
|
Re: Evaluate a DXL script in the current context Mathias Mamsch - Tue Nov 10 15:45:14 EST 2015 Hello Joseph,
you can hand any variable to an eval_ DXL context using addr this way:
DxlObject dx = new()
string sCode = "
DxlObject dx = addr_ (" ((addr_ dx) int) ")
// ... work with dx ...
"
However you need to be very careful with what you hand out of the eval context. If you put something inside a skip list or dxl object or such from inside the eval context, chances are high, that it will be destroyed after eval context ends. I found it is save to append to a Buffer declared on the outside from the inside of the eval context. You can also pass a reference to the eval_ context, allowing you change the outside variable, but this needs to be handled with even more care: Buffer buf = null string sCode = " Buffer &buf = addr_ " ((addr_ (&buf)) int) " buf = create() // ouch! will change the outside buf " Ouch, because inside the above code the eval will be able change the outside buf variable, but the allocation will be freed after the eval context ends. One important note regarding the addr_: The eval string will end up like so: " Buffer buf = addr_ 1234567" where 1234567 is the content of the variable (or memory address if you use the reference). You need to be especially careful on DOORS 64 since memory addresses are 64 bit and this kind of code will fail for high memory addresses. Hope that helps, regards, Mathias
Hi Mathias !
I suspected this response ... you said:
What do you mean by "changes are high" ? ;-) Could you please rephrase this sentence ?
I'm sure it is an interesting info, but I'm not sure to understand.
Anyway I'll do some tests to qualify that.
thank you. Joseph? |
Re: Evaluate a DXL script in the current context jaracic - Wed Nov 11 04:13:32 EST 2015 Hi Mathias !
I suspected this response ... you said:
What do you mean by "changes are high" ? ;-) Could you please rephrase this sentence ?
I'm sure it is an interesting info, but I'm not sure to understand.
Anyway I'll do some tests to qualify that.
thank you. Joseph? With "chances are high" I meant, that there are only very few types that you can pass back from the eval_ context to the main program. These are of course non allocated types like: int, real, char. Then there are the strings. Strings are normally also not safe to pass back, but I found, you can have them persisted in the string table which makes them save to pass back. However If your production code relies on this, welcome to 'Hack Land'. So I won't even show how this is done here, you can find some example on the forum if you search cleverly. So to make that as simple as possible, that the only safe way I know of passing something back from the eval are these: Buffer buf = create(); Skip sk = create() string sCode = " Buffer buf = addr_ " ((addr_ buf) int) " Skip sk = addr_ " ((addr_ sk) int) " buf += "Hello"; // safe, buffer was created on the outside, string will be copied to the buffer put (sk, 1, 1); // safe, Skip was created on the outside and elements are ints // unsafe! String will be freed after eval ends, so skip value will wind up as garbage // put (sk, 1, "Hello"); " So as you can see, you generally should only *read* data inside the eval_. If you plan to create complex data structures inside your eval_ context (like (probably nested) skips, etc.) and pass them back to your main program you are kind of hosed. You need to think about a way to 'marshal' that information to a buffer and then 'unmarshal' it from the main context again.
Regards, Mathias |
Re: Evaluate a DXL script in the current context Mathias Mamsch - Wed Nov 11 06:27:04 EST 2015 With "chances are high" I meant, that there are only very few types that you can pass back from the eval_ context to the main program. These are of course non allocated types like: int, real, char. Then there are the strings. Strings are normally also not safe to pass back, but I found, you can have them persisted in the string table which makes them save to pass back. However If your production code relies on this, welcome to 'Hack Land'. So I won't even show how this is done here, you can find some example on the forum if you search cleverly. So to make that as simple as possible, that the only safe way I know of passing something back from the eval are these: Buffer buf = create(); Skip sk = create() string sCode = " Buffer buf = addr_ " ((addr_ buf) int) " Skip sk = addr_ " ((addr_ sk) int) " buf += "Hello"; // safe, buffer was created on the outside, string will be copied to the buffer put (sk, 1, 1); // safe, Skip was created on the outside and elements are ints // unsafe! String will be freed after eval ends, so skip value will wind up as garbage // put (sk, 1, "Hello"); " So as you can see, you generally should only *read* data inside the eval_. If you plan to create complex data structures inside your eval_ context (like (probably nested) skips, etc.) and pass them back to your main program you are kind of hosed. You need to think about a way to 'marshal' that information to a buffer and then 'unmarshal' it from the main context again.
Regards, Mathias Crystal clear Mathias. Thank you. |